1. Field of the Invention
The present invention relates generally to computer software. More particularly, the present invention relates to network management software.
2. Description of the Relevant Art
The field of network management involves the management of networked devices, often remotely. A computer network is a linked group of two or more computers. Generally, networks may be classified as Local-Area Networks (LANs) or Wide-Area Networks (WANs). In a LAN, the computers or devices are typically connected together within a xe2x80x9clocalxe2x80x9d area such as a home, office, or group of offices. In a WAN, the computers or devices are typically separated by a greater distance and are often connected via telephone/communication lines, radio waves, or other suitable means of connection.
Networks are usually classified using three properties: topology, protocol, and architecture. Topology specifies the geometric arrangement of the network. Common topologies are bus, ring, and star configurations. A network""s protocol specifies a common set of rules and/or signals, such as Ethernet or Token Ring, that the networked devices use to communicate with each other. A network""s architecture typically specifies one of the two major types of network architecture: peer-to-peer or client/server. In a peer-to-peer networking configuration, there is no server, and computers simply connect with each other in a workgroup to share files, printers, services, and Internet access. Client/server networks often include a domain controller to which all of the networked computers log on. This server may provide various services such as centrally routed Internet access, e-mail, file sharing, printer access, and security services.
Many types of devices may be managed over a network, such as printers, scanners, phone systems, copiers, and many other devices and appliances configured for network operation. Managing such devices tends to require that the data types of each device""s control parameters and signals be well defined. For example, a networked printer might have a Boolean status parameter that indicates whether the device is currently on or off and a control parameter which turns the printer on or off. The printer may also be capable of generating an alert signal indicating, for example, that the toner level is low. The network management software should be able to read and write these data correctly in order to manage the device. To do this, information about the data is required. Such information is referred to as metadata, or xe2x80x9cdata about data.xe2x80x9d Metadata may typically describe what type of data (string, integer, Boolean, structure) an object has and how the data are formatted. Metadata is essential for understanding information related to managed devices, as well as information stored in data warehouses. Typically, network management software manages a given device by storing and manipulating a representation of its pertinent data as a software object, herein referred to as a xe2x80x9cmanaged object.xe2x80x9d This object is the virtual representation of the device on the network.
FIG. 1a illustrates an example of typical elements of a telecommunications network. The telecommunications world is characterized by devices such as cell phones, cell phone towers and other kinds of towers 156, phone systems 151, faxes 152, routers 153, switches 154, satellite dishes 155, etc., which may be interconnected via networks 108a. In response to the network management needs of this technology sector, a conceptual framework for telecom network management called Telecommunications Management Network (TMN) was developed by the TeleManagement Forum (TMF). TMN defines the relationship between basic network building blocks, such as network elements, different network protocols, and operations systems, in terms of standard interfaces. Generally, a TMN system includes Agent hardware 150, Manager software 170, and Agent software 160. The Agent hardware 150 includes the managed devices such as those shown in FIG. 1a. The Manager software 170 includes any application used to manage a networked device. These manager applications, or client applications, may be installed and executed on one or more client computer systems 171a, 171b, . . . , 171n. The Agent software 160 includes the software interface between the Manager software 170 (for communications via network 108b) and the Agent hardware 150 (for communications via network 108a). The Agent software 160 may be installed and executed on one )r more server computer systems 161a, 161b, . . . , 161n. In some instances, the Agent software 160 and Manager software 170 may be installed and executed on the same computer system. The Agent software 160 may also reside, in whole or part, on the Agent hardware 150 itself.
One TMN approach to managing objects over a network is the Simple Network Management Protocol (SNMP), a set of protocols for managing complex networks. SNMP works by sending messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in Management Information Bases (MIBs) and return this data to the SNMP requesters. The metadata used by SNMO to describe managed object data variables includes the variable title, the data type of the variable (e.g. integer, string), whether the variable is read-only or read-write, and the value of the variable. SNMP works over the TCP/IP (Transport Control Protocol/Internet Protocol) communication stack. SNMP also uses UDP over IP, and also may support TCP over IP. It is widely held, however, that SNMP was developed as a simple xe2x80x9cquick fixxe2x80x9d and was never intended to be a permanent solution to network management. Consequently, one problem with SNMP is that the information it specifies is neither detailed nor well-organized enough to adequately serve the expanding needs of modern networking.
Another example of a TMN network management protocol is the Common Management Information Protocol (CMIP). In the U.S. the CMIP protocol is primarily run over TCP/IP, while in Europe it is generally run over the OSI (Open Systems Interconnection) communication stack and was designed to replace SNMP and address SNMP""s shortcomings by providing a larger, more detailed network manager. Its basic design is similar to SNMP: Management requests, management responses, and notifications are employed to monitor a network. These correspond to SNMP""s PDUs. CMIP, however, contains eleven types of messages, compared to SNMP""s five types of PDUs.
In CMIP, variables are seen as complex and sophisticated data structures with many attributes. These include: variable attributes, which represent the variable""s characteristics (e.g., its data type, whether it is writable); variable behaviors, or the actions of that variable that can be triggered; and notifications, or event reports generated by the variable whenever a specified event occurs (e.g., a terminal shutdown would cause a variable notification event).
As a comparison, SNMP only employs variable attributes and notifications, but not variable behaviors. One of the strongest features of the CMIP protocol is that its variables not only relay information to and from the terminal (as in SNMP), but they can also be used to perform tasks that would be impossible under SNMP. For instance, if a terminal on a network cannot reach its fileserver for a predetermined number of tries, then CMIP can notify the appropriate personnel of the event. With SNMP, a user would need to explicitly keep track of the number of unsuccessful attempts to reach the fileserver. CMIP thus results in a more efficient network management system, as less work is required by a user to keep updated on the status of the network.
A significant disadvantage of the CMIP protocol is that it requires more system resources than SNMP, often by a factor of ten. Thus, any move to CMIP from SNMP requires a dramatic upgrade in network resources. Another disadvantage with CMIP is that it is very difficult to program; the variable metadata includes so many different components that few programmers are generally able to use the variables to their fall potential.
Both of the above protocols have been implemented in a number of programming languages, such as C, C++, and Java(trademark). However, network management software which takes advantage of SNMP or CMIP must be written specifically for the language of the protocol implementation. In other words, SNMP-based and CMIP-based network management software is dependent upon a particular programming language and protocol implementation.
A middleware standard used extensively in network management is the Common Object Request Broker Architecture (CORBA), which is provided by the Object Management Group (OMG). CORBA specifies a system that provides interoperability between objects in a heterogeneous, distributed environment and in a way transparent to the programmer. Its design is based on the OMG Object Model, which defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. In this model, clients request services from objects (which will also be called servers) through a well-defined interface. This interface is specified in the OMG Interface Definition Language (IDL).
In CORBA, a client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters, if any. The object reference is an object name that reliably defines an object.
A central component of CORBA is the Object Request Broker (ORB). The ORB encompasses the communication infrastructure necessary to identify and locate objects, handle connection management, and deliver data. In general, the ORB is not required to be a single component; it is simply defined by its interfaces. The basic functionality provided by the ORB includes passing the requests from clients to the object implementations on which they are invoked. The ORB acts as the middleware between clients and servers. In the CORBA model, a client can request a service without knowing anything about what servers are attached to the network. The various ORBs receive the requests, forward them to the appropriate servers, and then hand the results back to the client.
In CORBA, a client first looks up the object (server) it wants to communicate with. The ORB, as a result of the lookup operation, returns an object reference (a handle) of the server to the client. The client then uses the object reference to invoke operations on the object as a function call in the chosen programming language. The ORB intercepts the client request, collects the information about the operation and the request parameter values, encodes it in IIOP, and sends it to the object (server). The ORB on the object side (server) translates the request into a programming language specific function call on the server object. The server object then processes the request and returns a response, if any. The ORB intercepts the response, encodes the response and its parameters into IIOP, and sends it to the client. The ORB on the client side then returns the response to the client as the return value of the function call originally made as part of issuing the request.
GDMO (Guidelines for Definition of Managed Objects) is a standard for defining objects in a network in a consistent way. With a consistent xe2x80x9clanguagexe2x80x9d for describing such objects as workstations, LAN servers, and switches, programs can be written to control or sense the status of network elements throughout a network. GDMO prescribes how a network product manufacturer must describe the product formally so that others can write programs that recognize and deal with the product. Using GDMO with ASN1, descriptions may be made of the class or classes of the object, how the object behaves, its attributes, and classes that it may inherit.
GDMO is part of the CMIP and also the guideline for defining network objects under TMN. The object definitions created using GDMO and related tools form a Management Information Base (MIB). GDMO uses Abstract Syntax Notation One (ASN1) as the rules for syntax and attribute encoding when defining the objects. Abstract Syntax Notation One is a language that defines the way data is sent across dissimilar communication systems. ASN1 ensures that the data received is the same as the data transmitted by providing a common syntax for specifying application layer (e.g., program-to-program communications) protocols. Each communications system contains a similar ASN1 encoding/decoding scheme written in the language used on that particular system. When one system wants to send data to another, the first system encodes the data into ASN1, sends the data, and the second system receives and decodes the data using the decoder written in the language used on that system.
In response to the difficulties presented by SNMP and CMIP, the Object Management Group (OMG) and Joint Inter-Domain Management (JIDM) have defined Interface Definition Language (IDL) for network management, which is used to access object instance data and may be used across a plurality of programming languages and across a plurality of platforms. JIDM IDL allows programmers to write only one set of interfaces for a particular object across multiple programming languages, rather than having to write a new set of interfaces for each programming language. Although the use of IDL as a programming-language-independent and platform-independent interface to define CORBA services and objects greatly improves the ease with which network objects may be managed, there is a significant problem in that for each TMN object to be managed, an IDL interface must be defined and compiled. This problem leads to a great proliferation of object interfaces which must be learned to manage the network effectively. The management of such a large number of compiled object-specific interfaces requires significant memory and disk space resources and degrades the performance and scalability of management applications. Whenever a new object type is to be added to a network, the system must be shut down and recompiled with the new object interface. With the great number of object interfaces involved, compile times may be exceedingly long. Because many network management systems, especially in the field of telecommunications network management, are expected to be operable continuously with no downtime, adding or removing managed object types may become problematic.
Therefore, improved systems and methods for managing network devices are desired.
The problems outlined above are in large part solved by various embodiments of a system and method for generic and dynamic mapping of managed object metadata as disclosed herein. The framework may provide a suitable system for managed object data type conversions between various data description languages, such as an interface definition language, and an abstract syntax notation.
In one embodiment, when a CORBA client application invokes a management request on a Request Gateway, the Gateway may convert the request parameter values in IDL data types to PMI""s ASN1Values. PMI (Portable Management Interface) is a proprietary C++ API that is used in developing C++ management and agent applications (managers and agents). Similarly, when the Gateway receives a response from an enterprise manager, it may convert the response parameter values in PMI""s ASN1Values to values in IDL data types. This conversion facility may be used extensively in both request and event network traffic, and so in one embodiment, common libraries may be used.
In one embodiment, one of the data types may be represented in a generic interface description language which is operable to describe interfaces to managed objects across a plurality of platforms and across a plurality of programming languages, and is class independent. As used herein, the term xe2x80x9cclass independentxe2x80x9d refers to the property that a single interface may be defined to describe substantially all data types and all managed objects. Given the number of different types of TMN objects one may need to manage on a network, having a single object interface for all of them saves significant resources in that there is no need to statically compile and store separate interfaces for the many objects, which may increase the scalability of a network management system dramatically. This also means that one may add a new object to the system without bringing the system down to compile a new interface, making it much easier to maintain system operations with little or no downtime.
Because there is potential for different mappings of IDL data types to ASN1 data types, in one embodiment, two separate libraries may be used: a converter framework library and a converter implementation library. The use of converter implementation libraries may allow various different mappings to be used easily by implementing them as plug-in modules. In one embodiment, the two libraries may include an ASN1 converter framework library and a C++ IDL-ASN1 converter implementation library. The added benefit of this approach is that the converter framework library can be reused to support conversion of ASN1 types and values to other formats like TL-1, simply by providing an appropriate converter implementation library corresponding to the IDL-ASN1 converter implementation library.
In one embodiment, the framework library provides a collection of classes that may be used by the clients of the converter libraries. Most classes in the converter framework library are handle classes (or wrappers) to the real implementation (or body) classes in the converter implementation library. Framework classes hide the details of the real implementation classes and provide a simple, consistent interface to any data type converter via IDL. The converter implementation library provides the implementation needed by the framework to function properly. In one embodiment, the converter implementation library is operable to convert data types between IDL and ASN1 types. Users of converters typically do not interact directly with the converter implementation library. Instead, as described above, they use a generic converter class of the converter framework. The converter implementation library may provide the actual data type converters.
For example, in one embodiment, C++ IDL less than -- greater than ASN1 converters may create a class IDL Value, subclass of a framework abstract class OpaqueValue, to hold C++ IDL data. The IDLValue class is a data-holder used to hold IDL values in CORBA::Any, the CORBA generic data type. Therefore, only one interface may be used for converting any data type. In an alternate embodiment, TL1 less than -- greater than ASN1 converters could define their own subclasses to hold data specific to that domain. The use of a single generic primitive data type, along wvith the simple container types of set and sequence, provides an efficient, simple approach to managing managed object metadata across multiple platforms and multiple programming languages, in addition to providing a generic interface to all managed object classes.
The combination of using IDL and the generic type  less than any greater than provides an efficient, generic solution to mapping data types across multiple platforms, multiple programming languages, and multiple object classes. The fact that the framework described herein accommodates a variety of plug-in modules for mapping other data types to and from IDL further enhances the suitability of the system and method for a generic and expandable solution to data and metadata type conversions.